home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 990 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.3 KB
  1. From: mforget@elfhaven.ersys.edmonton.ab.ca (Michel Forget)
  2. Subject: Re: GEM apps, in general
  3. Date:     Wed, 20 Jul 1994 23:12:58 -0600
  4. Precedence: bulk
  5.  
  6. Hello Evan,
  7.  
  8. >========================================================================
  9. >I'm not sure I follow your comment.  My -experience- is that I do not know
  10. >assembly language, and therefore have no real use for an assembly level
  11. >debugger.  What on earth can you possibly object to in that?
  12. >========================================================================
  13. >
  14. >In my EXPERIENCE I have used both kinds of debuggers.  Both have their
  15. >uses.  I do know assembly language, 3 or 4 of them, but I fail to see
  16. >what ANY of this has to do with GEM.  Will using TIMER events slow the
  17. >system?  Yes!   Why?   Because the program is running instead of waiting.
  18. [...]
  19.  
  20. I think you got confused somewhere.  You quoted my comment, then went
  21. on to blast me for things I never said.  You meant Ken, right?
  22.  
  23. >So, do us all a favor, and work to illimintae polling from your apps.
  24.  
  25. Just in case someone thought your comments were directed at me; none of
  26. my applications use the sort of polling being discussed.  As Even says,
  27. I call evnt_multi() once and wait for something to happen.  When it does,
  28. I deal with it and then call evnt_multi() again.  I do not use timer
  29. events (except once or twice to slow down a visual effect, and that can
  30. be disabled).  I completely agree that calling evnt_multi()/objc_find()/
  31. wind_find() in a tight loop would be a nightmare for MultiTOS (or any
  32. other MultiTasking operating system).
  33.  
  34. >Of course, rectangles are just 4 words, or a pointer to 4 words.  Using
  35. >them is easy.  Drawing graphics for a large pixel-map takes a considerable
  36. >amount of CPU power.  The overhead of the rectangles is nothing by
  37. >comparison.  That is why I use point-to-type and let my background windows
  38. >scroll in TOSWIN.
  39.  
  40. Your example source code was interesting.  Do you have any that shows how
  41. to scroll a window using the rectangle list and raster copies?  That
  42. would be a pretty complex operation, I would think.
  43.  
  44. >8K chunks is best.   When running protected all memory is dolled out in
  45. >8K chunks anyway, so you might as well only Malloc() in that size.
  46.  
  47. That would defeat the purpose, though.  If you allocate memory in 8K
  48. chunks, then load a 200K document, TOS 1.0 is toast.  Any ideas?
  49. As for how this relates to GEM programming, how about this?  "Memory
  50. allocation for raster copies from the screen to a buffer."  (Flimsy,
  51. huh?)  :)
  52.  
  53. >1 - No Polling
  54.  
  55. Agreed.
  56.  
  57. >2 - No vector grabbing!
  58.  
  59. This depends on your application.  If it is an AUTO folder program
  60. designed to replace the file selector, you need to  grab a vector.  A
  61. regular application, though, should not grab vectors.
  62.  
  63. >3 - All graphics in windows (including window 0 with proper wind_set)
  64.  
  65. What?  Why would you want to do anything to window handle 0 (the
  66. desktop)?
  67.  
  68. >4 - Always walk rectangles
  69.  
  70. Of course.
  71.  
  72. >5 - Don't assume screen or memory formats.
  73.  
  74. Always check for Mxalloc() and use that if it is available.
  75.  
  76. >6 - Free unused memory
  77.  
  78. Well, sure.
  79.  
  80. >7 - No polling!
  81. >8 - No vector grabbing!
  82.  
  83. Deja Vu!
  84.  
  85. >9 - No form_do() or other locking calls.
  86.  
  87. Hold on, though.  An alert box is a "locking" call, yet there are
  88. legitimate uses for it.  You can have alert boxes in windows (ESS-Code
  89. does this) but they should at least be modal to the application showing
  90. the alert box.
  91.  
  92. >10 - no dialog-ware or alert-ware
  93.  
  94. For this I agree, sort of.  If the dialog is in a window, then there is
  95. not problem (since it is non-modal).  Using form_do() would be a bad
  96. idea, though.
  97.  
  98. >========================================================================
  99. >If an ACC doesn't call menu_register, does it still take up a `slot'?
  100. >========================================================================
  101. >
  102. >Depends  on the internals of GEM.  Good question!!!  I can't answer that.
  103.  
  104. I have a feeling that it does.  Maybe not, though, since you can have
  105. two or three entries in one accessory slot.
  106.  
  107. You know, I'm learning a lot from this list.  Not all of it is about
  108. GEM programming, but I have no problem with that...  :)
  109.  
  110.  
  111. -- 
  112. Michel Forget           \\   mforget@elfhaven.ersys.edmonton.ab.ca    //
  113. Electric Storm Software  \\  ess@tibalt.supernet.ab.ca               //
  114. PGP Public Key Finger. = 1F C0 D3 FE 40 51 7F 47 F3 4A C6 AD 6E 02 71 85
  115.